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I  INTRODUCTION 


INPUT  has  been  forecasting  detailed  residual  values  for  IBM  and  software- 
compatible  mainframes  since  1977  and  for  selected  peripheral  products  since 
1979.  The  emphasis  of  the  Residual  Value  Forecasting  Series  has  always  been 
upon  analysis  and  anticipation  of  significant  product  development  and  pricing 
strategies^rather  thani.mere  reporting  of  used-market  prices. 


The  inauguration  of  the  Large-Scalel Systems  Directions  program  reflects  this  \s 
emphasis.  This  particular  report  "Targe-Scale  Systems  Directions;  Midyear 
Updtrf^  ties  back  to  analysjs  w|-nph  began  in  the  last  report  in  the  Residual 
Value  Forecasting  Series  and  concludes  a  general  overview  of  large-scale  ^ 
systemfdirectionsf^'  ^ 

Tjjg^Residual  Value  Forecasts  for  Large-Scaje  Systems^jpecember 
1 983  report^contained  a  general  analysis  of  IBM's  approach  to 
distributed  processing  in  view  of  the+f  ^recently  announced  3270  PC, 
XT/370„and  8150. 

r 

The  first  large-Scale  Systems  Directionsreport  ("Larqe^cale  System  N 

tt<  *       f  'r 

pirectionsifDisk,  Tapes^nd  Printer  Svgtpnq^.Mnrrh  1984)  contained  a 

comprehensive  systems  view  of  directions  in  fcrge-scale  peripheral 

systems. 


is  report  contains  a  general  analysis  of  the^hjfting  role  of  large- 
scale  systems,  and  the  anticipated  changes  whteh  can  be  expected 
during  the  I990's  (Next -yew  wo-wiH  be^aiu^stingqr^skluqbvofuHi^yfec. 
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,29ofi< 


syp  t  Ic     !  mo!  tioqs  i  t:  •• 


rH  to  ?i?.v|pnr>  'n* 


The  three  reports  should  be  reviewed  as  a  framework  within  which  to 
view  more  detailed  analysjs  within  specific  areas^bichwill  appear  in 
future  issues  of  Larqe-Scale  Systems  Directions. 

Chapter-Ufof  this  report  contains  the  analysis  of  the  shifting  role  of  large- 
scale  mainframes.with  special  emphasis  upon  the  key  role  of  IBM  systems 

The  recently  announced  IBM  3280  magnetic  tape  subsystem  is  analyzed 
in  terms  of  its  impact  (or  lack  of  impact)  on  3240  tapej'systems. 

The  impact  of  the  made  h -of  4h^  308X  series  is  reviewed-and  projected 


residual  values  of  these  new  systems  and  included. 


f 


U   v^^JCu6   s^JU^Q  ^JU^.  ^ 
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II        THE  SHIFTING  ROLE  OF  LARGE-SCALE  SYSTEMS 


A.       THE  CENTRAL  ROLE  OF  IBM  SOFTWARE 


OBSERVABLE  TRENDS 


>  The  most  obvious  observable  trend  is  that  the  demand  for  large  mainframes 

seems  to  be  increasing  exponentially.  Generations  of  large-scale  processors 

will 

««d-being  announced  with  increased  frequency.  The  IBM  Sierra j&  reportedly 
•to^be  announced  in  late  1984,  but  the  follow-on  Summit  series  is  already 
removed  for  1988  announcement.  The  quest  for  MIPS  seems  unending. 

>  There  is  an  underlying  trend  which  fuiljejs  the  MIPS  requirements—IBM 

software.  This  is  the  year  of  MVS/XA,  and  DB2  will  join  IMS  on  large  IBM  \\-) 

mainframes;  the  combination  of  the  two  should  be  enough  to  keep  the 

qwirople,  process  or  (j)iM&)  ?n  ^ 

reported  5CHVUPS  Sierra  quad  busy.  In  fact,,  if  comDetitieo  ape  right,  and  an 

'  ^m^Jhg^ors»»id^   

IBMdual  processor  only  gets  1 .8  ^Xfthe  uniprocesso/,^^|he^uad  only  gets 

I*      I.J  times  the  dual  processor,  you  will  only  get  33.75  MIPS  anyhow.yTtiM  has  \QJ 

stated  that  MVS/XA  will  runjoutSbfJgas  in  the  late  1 98(r^ao3f  MVS/XB  is 

being  predicted  for  announcement  in  1988— just  in  time  to  use  up  all  the  MIPS 

the  Summit  series  can  provide. 


IBM  software  has  sold  a  lot  of  iron,  and  it  has  evolved  over  the  last  20  years 
based  on  concepts  more  appropriate  for  a  bygone  era  when  processing  power 
was  expensive,  random  access  memory  was  limited,  and  jobs  were  entered 

> 
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through  a  card  reader.  The  software  was  not  designed  for  todays  network 
environment,  and  the  hardware  was  not  designed  to  run  today's  software.  As 

someone  familiar  with  the  history  of  System/360  stated  recently:  "XA  really 

5 


standing,  for  extended  accommodation^ 


That  has  been  the  case  over  the  last 
X 

20  years  as  multiprogramming,  interactive  processing,  DBMS's,  virtual 
storage,  and  multiprocessing  capabilities  have  been  added  to  what  essentially 

e 

started  as  a  stacked  job  monitor.  However,  the  IBM  trend  has  been  consistent 

in  one  regard— the  progressive  centralization  of  systems  on  ever-larger 

r-  A  A 

mainframes  under  the  control  of  evep^more^omplex  systems  software. 

Parallel  with  this  IBM  emphasis  upon  centralizationjias  been  a  technological 
trend  toward^distributed  processing— first  to  minicomputers  and  later  to 
microprocessors.  The  economies  of  distributed  processing  have  been  clear  for 
well  over  K)  years/|ane^eight  years  agoyiNPUT  recommended  the 
centralization  of  processing  on  large  central  mainframes^o  be  followed  by 
"the  orderly  distribution  of  processing"  to  minicomputers  and  intelligent 
terminals.  Despite  lip  service  to  distributed  processing,  IBM's  primary 
strategy  has  been  to  preserve  (and  enhance)  the  dominant  role  of  large 
mainframes  in  irs  Systems  Network  Architecture  (SNA).  (IBM's  distributed 

processing  strategy  was  analyzed  in  INPUT'S  "Residual  Value  Forecasts  for  / 

'  "  1/ 

Large-Scale  Systems  .  December  1983.) 

One  additional  trend  has  been  to  refer  toycommercial  computer  applications 

asj  data  processing  systems,  management  information  systems,  decision 

support  systems,  and  expert  systems.  To  date,  this  trend  has  represented^  ^  ^  ifctl*** 

refinement  in  terminology  more  than  it  has  change  in  substance,  but  /t  does- 

give^some  indication^of  what  is  expected  of  large  mainframes  when  they  are 

not  running  payroll  and  accounts  receivable  systems. 

OBVIOUS  IMPLICATIONS 


It  is  obvious  that  large  mainframes  are  doing  something  more  than  the 
arithmetic  required  to  run  business  enterprises.  A  single  IBM  3084  can 


2* 
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perform  more  arithj§\jjic  operations  than  the  entire  labor  force  of  the  United 
Statej^  In  fact,  a  single  3084  should  be  able  to  perform  all  the  arithmetic 
operations  necessary  to  process  payroll  and  accounts  receivable  for  the  entire 
United  States. 

o        Even  allowing  for  processing  data  input  and  formatting  reports,  it  is  obvious 
that  a  large  mainframe  hs  more  thn  enough  processing  power  for  even  the 
largest  corporationyrequired  commercial  applicationsJjTAsk  most  companies  ^o0 
wh^jaj  their  major  mainframe  applications  are  now  ana^weife  20  years  agor^nt^'^a-^       ^ll  Cid 

^fitiX    there  really  has^ne*  been  vef^much  change.  However,  installed  processing 
power  in  the  corporate  data  center  has  increased  by  a  factor  of  at  least  100 
over  the  last  20  years. 

o        This  is  not  quite  so  difficult  to  understand  if  it  is  recognized  that  subs+ontkiWy 

less  than  10%  of  mainframe  execution  time  is  spent  running  user-written 

code.  The  rest  of  the  time/'the  processor  is  busy-dwwg  fne  operating 

system.  Obviously  the  operating  system  must  be  doing  a  lot  of  very  important 

work  to  justify  this  expenditure  of  resources.  Indeed,  the  three  broad 
e 

objctives  of  operating  systems  can  hardly  be  disputed.  They  are: 
A 

Maximum  ease  of  use. 

Maximum  use  of  equipment  (thereby  increasing  efficiency  and  reducing 
the  cost  per  user  by  showing  resources). 

Effective  development,  testing,  and  introduction  of  system  function 
without  at  the  same  time  interfering  with  service. 

o         It  is  difficult  to  imagine  the  terrible  state  of  affairs  wS^+€^  would  exist  today 
if  we  did  not  have  MVS/XA  to  address  these  objectives.  By  implication, 
systems  would  be^much  more  difficult  to  use,       ess  efficient  in. use  of 
hardware,  and  more  disruptive  whenever  changes  ate  introduced. 
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■few 


Operating  systems  are  concerned  with/some  very  practical  problems  whteh 

/  *  6 
have  presented  a  considerable  intellectul  challenge  over  the/ast  20  years.  A 

great  deal  has  been  accomplished     solving  these^problems/jH*e*such  a 

substantial  portion  of  total  compuTe^f^soGrces  is  devoted  to  the  solutions^  is 

important  to  understand  roughly  what  they  are:  f 

The  first  is  referred  to  as  process^anJ^it  concerns  the  problems  of 
concurrency  (both  device  and  programs)  in  a  multiprogramming 
environment.  The  timing  required  to  permit  user  programs  to  execute 
in  parallel  without  interfering  with  each  other?  is  extremely  intricate 
when  resources  must  be  shared. 

Memory  management  in  a  multi-jyser  environment  creates  an  extremely 
complex  problem^specially  if  it  is  deemed  necessary  to  create  the 
illusion  that  enormous  amounts  of  main  memory  exist  for  each  user. 
Virtual  storage  concepts  have  been  developed  as  the  primary  means  of 
solving  the  memory  management  problem. 

The  protection  and  securitj^s  of  shared  data  has  created  problems  of 
access  control  and,  more  recently,  information  flow- underlying  these 
technical  problems  is  the  potentially  more  important  question  of 
privacy. 

Scheduling  and  resources  management  of  large  systems  in  order  to 
achieve  the  efficient  use  of  hardware  resources  has  been  an  especially 
irritating  problem  for  computer  scientists.  This  is  true  because  it  has 
been  found  that  techniques  from  operations  research  and  industrial 
engineering  sometimes  provide  answers  which  conflict  with 
architectural  concepts  of  both  hardware  and  software.  (Hardware 
vendors  seem  content  to  leave  the  more  complex  scheduling  and 
resource  management  problems  to  computer  scientists  and  users.  This 
is  not  surprising.) 


IX 
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The  combination  of  all  pf  the  above  presentya  specific  problem  of  how 

operating  systems  themselves  should  be  structured  (system  structure). 

IBM's  highly  centrtized  approach  has  been  the  emergence  of  the-— 
"   I  a,  Ccn<.epte>* 

— *   luncepl  of  v^r^ua^iYiachinei  (VM^^Computer  scientists  are  quick  to 

point  out  that  it"  wofitnot  introduce  a  new  concept  of  systems  desigrn^ 

but  readily  admit  >ffacJlitate^introductior|B  of  change. 

Considering  the  changes  in  hardware  technology  wbieh  bos  occurred  over  the 

last  20  years^it  would  seem  obvious  that  many  of  the  functions  previously 

assigned  to  software  could  perhaps  be  more  easily  and  economically  bo 

assigned  to  hardware.  Indeed,  it  has  been  necessary  to  provide  hardware  to 

implement  certain  operating  systems  functioni(such  as  virtual  storage). 

A 

u 

In  addition,  the  basic  premise  of  shared  use  of  expensive  computer  power  must 

A 

be  questioned  since  it  has  become  more  economical  to  provide  each  individual 
with  enough  personal  computer  power  to  satisfy  a  high  percentage  of  their  Q^ 
processing  requirements.  In  other  words,  can  many  of  the  problems  solved  by 
operating  systems  be  avoided?  This  is  an  especially  pertinent  question  as 
regards  the  process^ontfresource^nd  scheduling  problems  mentioned  above. 

The  conclusion  must  be  reached  that  large  mainframes  (and  associated 
software)  are  required  primarily  to  maintain  large  data  bases  and  to  provide 
processing  power  for  calculations  wmdS  cannot  be  realistically  performed  on 
distributed  systems  (minicomputers  and  microprocessors).  For  example, 
calculations  w-hteh  would  require  hours  or  days  on  a  personal  computer  would 
not  be  deemed  realistic.  The  question  now  becomes  whether  an  IBM  3084 
operating  under  MVS/XA  is  an  effective  or  even  appropriate  way  to  provide 
these  services. 


3.       OBSCURE  *MPA€-£S 


In  the  early  days  of  OS/360  a  system  programmer  observed:  "When  you 
consider  what  it  is  doing,  it  is  amazing  it  works  at  all."  Since  then  IBM 
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operating  systems  have  become  so  complex  that  no  individual  can  comprehend 

what  they  do,  much  less  how  they  do  it.  there  has  been  general  concensus 

that  IBM  operating  systems  do  an  awful  lot/ but  that  they  are  not  very 

efficient  at  doing  what  they  do.  One  time,  the  overhead  of  IBM  operating 

v  * 

systems  has  come  to  be  an  accepted  fact  of  life.  This  blind  acceptance  is 
dangerous  because  it  distorts  realitWfH  is  necessary  to  question  what 
software  does  to  you  as  well  as  whaf  it  does  for  you. 

The  case  of  virtual  storage  is  a  classic  example  of  obscure  impacts  w44ch 
continue^to  this  day.  Since  virtual  storge  remains  central  to  IBM's  (and  the 
industrte)  approacrrto  memory  management,  it  is  important  to  understand 
both  i{js^  history  and  current  status. 

IBM's  research  on  virtual  storage  started  when  the  largest  memory^f 

IBM  systems  was  approximately  a  quarter  of  q,$fcegT'^be  discovery  of 

"local it#B  of  reference"  in  matric6  and  the  innefer  loops  of  Fortran 

y  A  A  i=      1  --— 

programs^convinced  IBM  that  paging  was  more  efficient  than  other 

methods  overlaying. 
A 

Questions  concerning  local it^s  of  reference  in  commercial  applications/^ 
^where  s+or+ng  and  decision  tables  (or  structures)  are  commorj,  were  not 
considered,  understo^qcLor  researched. 

T 

The  eventual  problems  with  "thrashing"  (described  as  a  nearly  total 
collapse  of  processing  efficiency)  in  early  implementations  of  virtual 
storage  systems  were  described  as  ."a  counter-intuitive  mysteryM  but 
the  impact  was  quite  vis<?ble^processing  of  user  programs  virtually 
stopped  as  the  system  swapped  programs  and  data  in  and  out  of  main 
storage. 

While  rne^^rtormance  degradation  is  less  visible  today,  it  can  be 
assumed  that^rnrough^ut  impae?  remains.  There  is  an  intuitive 
attraction  to  getting  work  into  the  system,  processing  it,  and  getting  it 
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out.  (This  feeling  was  expressed  by  Seymour  Cray  in  the  early  days  of 
virtual  storage  systems,  and  the  advisability  of  pushin  short  jobs 
through  the  system  as  rapidjgjy  as  possible  was  proven  by  research  in 
the  late  I96(rs.j  Virtual  storage  systems  assure  that  the  process  of 
bringing  program*  and  data  togethe^for  processing  will  be  an 


extraordinary  exercise  in  control  and  scheduling. 


Today,  main  storage  has  become  large  enough  and  cheap  enough  to  - 
meet  the  needs  of  practically  all  users,  and  the  overlay  problem  is  noi 
longer  sufficient  reason  to  justify  the  use  of  virtual  storage.  The 
justification  for  virtua  (storage  is  now  stated  tc^be^the  built-in 
protection  and  process+isolation  mechanisms  are  inherent  in 

systems  such  as  MVS. 


reason  XA  was.  required^i^to  run  MVS.  Operating  systems  have 


taken  on  a  life  of  their  own.  It  can  truly  be  stated  that  large  IBM 
mainframs  exist  to  run  IBM  operating  systems,  and  o^ratingsyl^pns 
such  as  MVS/XA/oTily'lexist/to  run  large  mainframs.  2he  current 
situation  een  only -be  depicted  by  an  Esche/1  draw  ingMw4th.  the  user  «R 
cWwb    *  c,r^w  •^•rfr^  wWch-leadjboth  up  and  down.  — #  ' 

o         IBM  operating  systems  are  an  enigma,  but  it  is  important  to  understand  their 

value  now— before  IBM  turns  ir§  full  attention  to  the  protection  and  securjly---  ^ 

aspee4*^of  operating.systems.  There  are  disturbing  signs  that  user  DregoTrrg  — ^ 

to  be  further  4©+ete<Lfrom  ever  being  able  to  ei+hefunderstand  or  improve 
the  performance  of  systems  software. 

IBM's  current  trend  toward|^withholding  source  code  is  certainly  not 
designed  to  facilitate  etHrer^understanding  or  performance 
improvement  (regardless  of  motivation). 

The  trend  to  pre^cpnf  igured  operating  systems  (generated  by  IBM)  can 
also  be  considered  a  mixed  blessing.  While  t±*?eliminating  ePthe  need 
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for  systems  programmers  may  be  hailed  as  a  means  of  increasing 

productivity,  it  also  eliminates  the  primary  source  o|user  understanding 

of  IBM  hardware/software  systems.  (Beware  whenever  IBM  states  that 

"the  user  need  not  concern  himself"  or  "it  willHfansparent  to  the  end 
jftiiw  A  as 

usecJ'  jVhistory  has  shown  that  this  is  precisely  when  theuser^should 


concern  himself.*) 


Once  IBM  really  addresses  the  protection  and  security  problem,  the 

mystery  of  what  the  operating  system  does  and  how  it  de&»-!**will  be 
Iw-  uvlt  un\\  fee'. 

sealed  forever.  ^"You  can't  expect  your  system  to  be  secure  if  you  know 
what  we  are  doing  to  make  it  secure  for  you^  withbecorne  1-heTote; — 
Even  curiosity  about  what  is  going  on  will  be  suspect-^the  mystery  will 

A 

become  sacred. 


B.       LARGE  HOST  SYSTEMS 


ENORMOUS  DATA  BASE  MACHINES? 


IBM  corporate  strategy  is  essentially  large  mainframe  oriented. 
Minicomputers  ha|ye  never  assumed  their  proper  place  under  SNA,  and  micro- 
processor^(personal  computers)  are  to  be  viewed  as  intelligent  workstations 
heavily  dpendent  upon  large  host  systems.  In  fact,  IBM  is  counting  on 
intelligent  workstation^  control  the  demand  for  minicomputers  and  to 
rejuvenate  the  demand  for  large  mainframes.  (See  Residual  Value  Forecasts 
for  Large-Scale  SystemsMfpecember  1983.) 

The  primary  role  for  large  central  mainf^pme^can  best  be  described  as 


enormous  data  base  machines.  -The  projected  structure  of  distributed  data 
bases  was  presented  in  INPUT's^Lnrge-Scgle  System|yPirectipn.s;^)jsk.  Tapeyv 
and  Printer  SystemswT^arch  1984.  There  seems  to  be  little  question  that  ^ 
IBM  is  confident  that  intelligent  workstations  will  make  enormous  demands 
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upon  central  host  systems  for  data^m  other  words,  IBM  has  already 
prescribed  a  new  role  for  large-scale  systems. 

This  section  will  examine  this  large-scale  systems  role  from  an  IBM  strategic 

•  ,    r   •         'Km     .  WC 
point  of  view,  and.examine  the  nrlbge-ts  wriTCn  can  be  expected  as  these  larae 

complex  systems  continue  to  grow.  }f  will  analyze  the  guestionsof  whether 

such  systems  are  economically  justified  or  even  technically  feasible. 

MAINFRAME  MIPS  AND  STORGE  BITS 

For  1 983,  IBM  reported  $10.7  billion  in  revenue  from  mediutrjjjmd  large-scale 
systems,  $1 1.0  billion  from  standard  peripherals  (tapes,  printersAand  disks 


primarily),  $8.0  billion  from  small  systems/office  products,  $4.6  billion  from 
maintenance  services,  $2.3  billion  from  systems  and  applications  software^nd 
$3.6  billion  from^ther^ 

Mainframes  and  standard  peripheral  count  for  a  total  of  $21.7  billion, 
add  appropriate  shares  of  maintenance  and  software  revenues 
(approximately  $4.5  billion^and  this  total  comes  to  $26.2  billion  or 
(%65.2)of  IBM's  gross  revenue^  $40.2  billion^ 

j  Standalone  peripherals,  revenues; primarily  magnetic  disk  storage,  were 

increasing  more  rapidly  tharftan^  other  area  (27.39(f  over*!  982).  It  has 

"=  \/l  A 

been  INPUT  position  for  sometkne  that  magnetic  disk  storage 

represented  a  key  growth  area  for  IBM  in  the  1980%  and  confirmed 


that  opinion. 


Buried  somewhere  under  small  systems/office  produces  are  personal 
computers.  While  financial  analysts  may  feel  th^  PC       lack  of 


market  acceptance  is  a  severe  blow  to  IBM's  overall  strateay,  or  that 
.  ok  Hreat-^ 

imfJowering^personal  computer  prices  may  seriously  n=*pee+  IBM's 

revenuesjj^there  is  no  guestion  about  the  forces  in  Armonk,  and  the* 

forces  is  on  large  host  systems  with  lots  of  disk  storage. 


fat 
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Both  the  distribution  of  data  bases  and  IBM's  IMS/DB2  data  base  architecture 
were  prevented  in  tW  *Carge-Scale  Systems  Directions:  Disk,  Tape,^pnnter 
Systemffifiarch  1 984  report ^^^t was  previously  cited.  The  functioning  of 
such  ^host  data  base  systerr^from  an  operating  systems  point  of  view  is 
presented  in  Exhibit  \\-%"^  ♦ 

\v> 

The  projected  (IBM)  distributed  data  base  environment  under  the   ,    ^  • 
centralized  control  of  large  host  processors  implies  a  return  to  a  later 
environment. 


The  extract  facilities  of  DB2  and  the  building  of  relational 
tables  will  require  batch  jobpchedulincj^ome  jobs  may  only  run 
for  minutes  and  others  may  require  hours  far  days). 

While  IBM's  proposed  operating  environment  does  not  permit 
updating  of  IMS  data  bases  directly  from  DB2,  it  is  inevitable 
that  changes  from  DB2  applications  will  be  batched  and  run 
against  IMS  data  bases.  (In  addition,  distributed  processors  will 
have  the  effect  of  batching  changes  for  central  data  bases  under 
any  circumstances.) 

Mirror  data  bases  and  backjup  is  the  name  of  the  game  in  an 
X  P 

environment  whep  the  sale  of  disk  storagejs  the  key  to  revenue 
to  growth^there  will  be  backups  of  backups  unless  careful 
planning  is  done. 

The  whole  micro-mainframe  link  concept  is  to  provide  for  the 
extraction  and  downjoading  of  planning  and  personal  data 
bases.  (If  tyefe  aren't  batch  request  on  the  best^lire  will  be 
problems  wrrrch  will  be  described  later.) 
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Requests  for  Heavy  computation  imply  batch  requests  (although 
some  users  may  expect  interactive  response  to  unreasonable 
requests).  (*) 


Against  this  batch  environment  it  will  also  be  necessary  to 
provide  interactive  support  (or  vise  versa).  For  the  type  of 


environment  envisioned,  processing  of  batch  and  interactive 
cannot  be  conveniently  separated  (or  scheduled  separately).  An 
<s.w  intelligent  workstation  may  share  3i n  iu 1 1  uwiuus /equest  for  a 
batch  run  against  a  sequential  file,  an  IMS  inquiry  and » JOIN 
and  SELECT  commands  against  relational  tables  under  DB2  a4+ 
^  w^o<?.         ~v      getng-qt  tho  came  time.  Ane^that  intelligent  workstation^may 

be  in  the  presiden&office.  JUtf^*^  ^ 

The  distributed  data  base  environment  wtrtcta  is  anticipated  because  of 
micro-mainframe  Jinks  is  going  to  bring  protection  and  securities  to  the 
fore  in  everybodiw  mind— and  for  good  reason. 

The  traditional  problems  of  access  can  only  get  worse  as  the 

new  generation^ackersAwithsuper  microprocessors  to  help  them/* 

 r  "y. — *■   Ssovv  S — 

\come  on-lineJL-and  there  will. be  as  much  (or  more)  concern  about 
internal  access  as  there  is  from  competitions  or  hobbyists. 

It  is  assumed  that  intelligent  workstation  will  generate 
increasing  amounts  of  data  and  information  and  that  there  will 
be  a  desire  to  update  data  bases  and  f  iles^bontamination  may 
become  more  of  a  problem  than  access  unless  updates  are  rigidly 
controlled. 


The  well-known  concerns  about  sychronization  and  integrity  will 

A 

still  be  justified^even  if  only  authorized  persons  are  permitted  to 
update  files^jjj&ata  base  management  is  not  going  to  become  any 


easier. 
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Some  automatic  means  of  file  and  data  base  certification  across 
data  bases  (IMS-DB2  for  example)  must  be  established^this  is  a 
nonj^ivial  problem  when  considered  inlthe  projected  distributed 
data  base  environment. 


The  problem  of  certification  is  closely  associated  with  the 
problems  of  information  flow  control^*r$+J£  currently  trouble 
information  scientists  and  have  not  been  solved.  (Simply  state^  rke  fyvz^ &>>Jj^J 
how  ciqVou  control  unauthorized  information  leakage  based  on 
authorized  use  of  specific  data  and  imaginative  analysis  of 
data?  It  is  a  good  question.) 

Encryption  hasn't  become  a  problem  yetjbecause  most  users 
(even  those  with  sensitive  data)  have  not  taken  the  security 
problems  seriously/idespite  exaggerated  and  sensational 
publicities  given  to  "computer  crime". 


When  IBMJnas  its  solution  tathe  securities  and 

protectiohoroblems  incorporated  in  its  largejhost  systems^h^  CWfc/-Je,£- 

whol^area  fs  going  to  receive  a  lot  of  high-level  attention^flnd-*-^ 

A  A  W 

you  can  be  sure  the  solution  is  not  going  to  be  cheap. 

t 

Even  this  general  description  offthe  large  host  data  base  mach^ine^ should  point 
out  quite  clearly  that  IBM's  distributed  processing  strateg^s  going  to  generate 
enormous  demands  for  mainframe^ MIPS  and  storage  bits.  In  fact,  INPUT  has 
recently  forecast  that  IBM  will  be  able  to  maintain  its,  traditional  growth  and 
become  a  $100  billion  company  by  1990  without  drastic^jhifts  in  emphasis 
from  its  current  lacje-scale  mainframe,  magnetic  disk,\intelligent  workstation 
strategy.  In  other  words,  SNA^will  continue  to  evolve  at  what  some  consider 


A. 

to  be  an  excruciatingly  slow  pace. 
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INPUT  predicted  in  it|s  last J_arge-^cale  System  that  IBM  will  be 


7- 


sful  in  slowing  acceptance  of  optical  disk  systems  vilueh  migh 
magnetic  storac 
the  1988-89  timeframe 


t  magnetic  storage  revenue  (or  facilitate  electronic  offices)  until 


During  recent  research  on  another  subject,  an  IBM  employee  stated: 
"We  have  made  a  lot  of  money  on  large  mainframejfor  a  long  time,  and 
we  think  it  can  go  on  forever."  (There  are  those  in  IBM  who  vjew  with 
alarm  potential  technological  imfSaets  on  IBM  strategy.Tw^assured 
^     nknthat  wejelt  IBM  would,  in  fact,  continue  to  make  a  lot  of  money 
from  large-scale  systems  through  the  1 980*s. 

The  fact  of  the  matter  is  that  SNA  makes  more  sense  at  this  pointjinfrime 
than  it  evejrt  ha^i  1  1 1  it1  The  controlled  distribution  ofjp^rocessing  onto 

minicomputers  has  been  technically  possible  and  economically  justified  for 
nearly  15  year  s)v@fi^  SNA  has  fought  that  prevailing  trend  for  the  last  10 
years.  THowever,  the  proliferation  of  micrdfprocessor--based  systems  and 
personal  data  bases  demands  central  control  if  chaos  is  ntrl  yoiny  to  result, 
en^lBM  certainly  intends  to  integrate  them  under  the  great  SNA  umbrella. 
is /probably)  the  only  way  to  go. 

In  addition,  the  opergtina  systems  environment  described  above  is  the  one  1MB 

u   1     .   .        fozm ,  ..      .         .  +v"- 

has  always  aimed  at^l^assumes  an  underlying  requirement  for  batch 
processing  and  that  interactive  systems  will  be  run  on  the  same  system.  While 
the  UNIX  buffs  are  correct  in  stating  that  MVS  (and  if& predecessors)  were 

n 

really  batch  systems  with  communications  and  termini  added,  it  will  be 
interesting  to  see  what  happens  when^and  if/cTsystem  designed  for  ll'^j 
interactive  processing  is  installed  in  the  environment  depicted  in  Exhibit  11-^ 

There  is  only  one  problem  with  all  this^the  processing  burden  of  IBM 
operating  systems^and  their  data  base  sub^^stems/'may  have  finally  reached 
the  point  where  processing  engines  may  not  be  available  to  drive  them.  It  is 
certainly  not^Hff  icult  to  picture  Sierra  being  overburdened  as  soon  as  it 
comes  oijHbf  thc?s^!n4^iriq^.ool<i»^'  ft  ■ 


Is 
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3.       THE  LIMITS  OF  GROWTH 

o        Earlier  this  year,  INPUT  prepared  two  executive  bulletin^  on  the  entropyN 
associated  with  data  and  information  in  the  environment  described  in  this 
report.  Our  fear  was  that  as  central  data  bases  grew  in  size  and  complexity, 
and  personal  data  bases  proliferated  chaos  would  inevitably  develop  because 
sufficient  energy  (human  and  computer  processing  power)  would  not  be 
available  to  maintainllrder  (or  organization).  ^^ie  these  bulletin^  were 
published  additional  research  has  been  done  wrrrch  supports  this  intuitive 
concern: 


Comprehensive  research  on  IBM  software  directions  has  revealed  that 

v  flow 

problems  of  data  entropjp  are  just^being  recognized  at  Yorktown 
Heights.  There  is  no  awareness  or  understanding  of  the  problem  •tf^i"A~Vl 
establishing  IBM  software  directions,  and  certainly  none  in  ianH  rt^airdl  W 
implementing  current  operating  or  data  base  systems. 


The  highly  centralized  nature  of  IBM's  approach  to  distributed 
processing  (essentially  that  described  by  INPUT  in  recent  reports)  will 
place  unanticipated  burdens  upon  host  systems  as  central  data  bases 
grow  (and  become  more  f  lexibleijana^new  functions  are  added 
(especially  those  associate  with  protection  and  security). 

y  V 

f  the  probability  of  catastrophic 

gjOVk  -  y  1 — ' 

central  systems  failure^unless  the  central  data  facilities  is  managed 
with  extreme  care.  This  implies  central  IS  control  not  only  of  the 
central  data  basefbut  al  so  contro^of  the  demands  made  upon  the 
system^for  data.  In  other  words,  just  because  someone  is  authorized 
to  have  access  to  data  does  not  mean  that  all  requests  can  be  serviced 
(even  those  from  the  president's  office).  There  is  no  indication  that 
IBM  will  provide  adequate  means  of  screening  such  request. 
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Even  highly  centralized  control  of  corporate  data  does  not  |nsure  the 
qualities  of  information  flow.  That  will  require  substantial  redundancy 


in  communicationyjYfiib  resultant  demands  upon  the  central  system. 

In  some  ways,  failure  of  thejcentral  system  is  preferable  to  the 
undetected  deterioration  in  the  qualities  of  data  and  information.  It  is 
probable  that  most  corporations  would  continue  to  function  without  the 
volumes  of  planning  data  from  the  central  facilities.  Most  operating 
decisions  are  still  made  based  on  relatively  simple  data  and  analysis^ 

which  are  available  at  the  local  level-end  executive  decisions  remain 

'     .   K  % 

pn^o  .\   intuitive  in  any  given  instance. 

This  brings  us  to  the  question  of  decision  support  systems  and  the  demands 

such  systems  will  make  on  even  the  largest  computer  system.  The  availability 

of  enormous  quantities  of  date  even  the  largest  computer  system.  The 

availability  of  enormous  quantities  ofdata'lbven  assuming  chaos  can  be 

averted—implies  that  analysis  tools  wnten  go  beyond  spreadsheets  must  be 

applied  to  assist  the  decision  maker.  The  current  emphasis  upon  knowledge 

bases  and  expert  systems  is  only  the  logical  extension  of  current  decision 

support  systems.  The  implementation  of  expert  system  in  the  general  business 
h  \ 

environment  ere^currently  ^/^Ti^^^J^^  on'^        e  avci' lat>i  1  i+y  of  data  and 
information^but^by  models  -re-  pcrrrHt  analysis. 

Even  relatively  simple  economic  models  (such  as  supplVand  demand)  ere 
beyond  the  current  state  of  mathematics.  John  von  Newmann 
expressed  the  need  for(  breakthrough  in  mathematics  ("Theory  of  Games 
and  Economic  Behavior")  over  40  years  ago,  end  progress  has  been 
extemely  slow. 

In  addition,  the  two  areas  where  analytical  tools  and  models  are  being 
developed— artificial  intelligence  and  operation^ research— exhibit 
similar  disturbing  properties.  Specifically^ 
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»      The  algorithms  of  operatior? research  depend  heavily  upon  probability 
theory  and  the  computational  cost  increase  faster  than  any  finite 
power  of  n.  For  example,  100!  comparisons  exceedjthe  capacity  of  any 
computing  resource  on  earth. 

The  same  type  of  limitation  exists  in  artificial  intelligence  where  the 
number  of  choices  increases  exponentially  (as  in  playing  chess). 


It  is  anticipated  thatrelational  data  bases  underlying  knowledge  bases 
to  feed  such  models  will  only  compound  the  problem. 


Thus,  it  appears  that  many  current  "solution^"  to  improve  the  decisionmaking 

5 

process  may  exceed  not  ^nh^  current  system  and  fifth^jgeneration  systems/ but . 

any  computing  facility  which  can  ever  be  constructed.  These  limits  of  growth 

in  large  computer  systems  to  v.ilv/h1  i  mi  li.iin  i  ntrgnrioo  of  problems,  und^ 

current  IBM  hardware/software  systems  are  pointed  in  a  direction 
fi 

rach  those  limits— soon! 
A 


wmcn 


will 


C.       DISTRIBUTION  OF  FUNCTION 


Hans  J.  Bremerman,  who  derived  the  physical  limits  of  data  processing  over 
20  years  ago,  has  stated: 

"We  call  an  algorithm/  transcomputable  if  irs,  computational  cost 
exceeds  all  bounds  that  govern  the  physical  implementation  of 
algorithms. 

"It  can  be  shown  that  the  exhaustive  search  algorithm  for  chess  is  n 
transcomputable.  The  same  is  true  for  many  algorithms  of  artificial 
intelligence  and  operations  reserch.  In  fact,  any  algorithm  whose 
computational  cost  grc^s  exponentially  with  a  size  parameter  n  is 
transcomputational  for  all  but  the  first  few  integers  n. 
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is  is  a  rather  disturbing  thought  and  many  people  have  chosen  to 
re  it." 

IBM  has  not  only  chosen  to  ignore  these  facts  but^has  proceaed  on  the 

assumption*  that  the  problem  is  really  to  ke&p  up  demand  for  large-scale 

processing  power  as^technology  gets  ^^er  an"  costjgetf  lower.  This  has  been 

done  with  complex  systems  software  vmreh  managed  to  consume  MIPS  faster 

than  IBM  releases  new  technology,  and  by  keeping  most  processing  on  the 

central  host.  The  processors  j!m^h  havejaeveloped  are  an  exaggerated 

tn        of  fl 
example  of  overfill  JpT  the  simple  arithmetic  required  for  account ingstype 

applications,  and  jj+ie  operating  systems  overhead^hq.3  bcofyTgccMogy  to  keep 

the  system  busy.    iAta*v**  *k 

Now,  with  the  role  wVncH  has  been  defirled  for  the  large-scale  systems  of  th«J- 

1 98(Ps— the  management  of  large  data  bases  and.computation  to  support 

A 

decision  making— the  total  hardware/software  system  runs^high  risk  of  failing 
for  lack  of  centn&F  processing  power.  All  that  is  needed  is: 

The  development  of  a  prototype  using  -a  relational  data  base  system  on 
an  intelligent  workstation  and  -thefi  going  into  operation  against 
corporate  data  bases  (and  files)  using  DBZ#on  the  mainframe, 

—  -    .    ^An.  analyst  running  a  "travel  ing*salesman-typeftprobl  em  on  his*      _  *x 
*   f  jo     4  And  \  a  £ov-  <z*/a.~*  ioj 

PC  for  iefrcities^tryjfig  ta  run  the  same  problem  for  100  cities 
on  the  3084Ke«4--<2- 

¥       The  limitations  and  costs  of  large-scale  IBM^nd  software^compatible 
systems  will  become  readily  apparent  aduiun<Hhe  fate  198ft*.  Both  the 
big.general^purpose  engines  and  the  supporting  software  will  be 
replaced  trr  the  I990j!^when  differentiation  and  mechanization  of 
current  large-scale  hardware  and  software  functions  occur  on  a 
massive  basis. 
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PROCESSING 


It  has  long  been  known  that  genera  ^purpose  computers  of  IBM/360-370 
architecture,  with  or  without  the  burden  of  IBM  software,  cannot  meet  the 
processing  requirements  of  certain  potential  applications.  The  classic 
example  beiogj-iumerical  weather  predictiorjjvhich  still  requires  approximately 
a  100-1000  fold  processing  increase  on  even  the  supercomputers.  This  ever~ 
growing  class  of  problems  has  been  differentiated_from  the  mainstream/and 
left  to  more  specialized  processors  from  CRAY^CDC^ 
rndustiy  effort  to  coontei  Hie  Japanese  f ifthrgerreration.  ■ 

I tlha^Xiiso] become  recognized  that  minicomputers  are  three  to  four  times 

more  cost-effective  than  large  processors  on  another  set  of  problems  (studies 
A 

for  nuclear  reactors,  solid-state  devices,  aircraft  design,  and  petroleum 

reservoirs) ■where-  turnaround  is  not  a  major  consideration.  Once  again  a  single 

aMf 

processor,  with  minimum  software  burden^operating  on  a  specific  problem^ 

results  in  substantially  more  cost-effective  operation. 

A 

More  recently,  microprocessors  have  demonstrated  that  they  are  substantially 
more  cost-effective  for  any  number  of  accounting  and  statistical-type 
operations  (to  say  nothing  of  text  editing  and  word  processing)  wh+eh  ar<£ 
representative  of  the  commercial  environment. 

The  problems  addressed  by  large-scale  operating  systems  (process,  memory 
management,  scheduling  and  resource  management,  general  systems 
structure,  and  even  protection  and  security)  arAall  alleviated  or  eliminated 
once  each  individual  and/or  each  application  is  assigned  an  undivided  iviiui  ^  1 
processor.  In  other  words,  the  assumption  of  o  scarce,  shared  caamautyjvjs 
been  replaced  wttrrc-ne  of  atrendance^-a  by  a-  ^ro\<LL\-i<r*.  o[  ohv"\&ML<. 

Looking  back  at  the  broad  objectives  of  operating  systems,  it  seems  apparent 
that  some  change  of  attitude  is  required. 
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Maximum  ease-of-use  can  certainly  be  achieved  in  an  environment 
where  the  processing  resource  is  not  shared. 


Maximum  use  of  equipment  is  based  on  the  scarce  commodities 

[artitude\and  shared  usg/of  the  past.  It  has  already  been  pointed  out 

that  the  distributed  processing  environment  is  more  cost-effective,  and  -fcKdi^ 

the  attitude  that  equipment  must  be  kept  bus>/s  a  thing  of  the  past.(  A 

personal  computer  is  more  comparable  to  a  telephone  than  a  308^^-'^  is  jn&a-^' 

a>  A  « 

for  the  convenience  of  the  user  and  x\o\a  piece  of  production 

equipment. 

The  effective  development  and  testing  of  functions  without  interfering 
with  service  is  a  problem  created  by  the  shared  facility  and  software 
itself.  Processors  are  going  to  become  more  like  their  smaller  hand- 
held brothers-I-^he  calculation^ As  more  functions  become  available  or 
necessary,  the  new  hardware/software  replacement  is  purchased.  For 
those  who  might  say  that  the  incremental  addition^  of  functions  under 
operating  systems  extends  the  life  offrhe  hardware,  it  can  only  be 
pointed  out  again  that  large  mainframe  life  cycles  are  getting  shorter, 
and  operating  systems  are  the  primary  cause. 

The  point  is  that  processors  are  going  to  h|e  differentiated^based  on  use  and/or 
application  down  to  a  relatively  fine  levejj;Ahere  will  be^specialized 
processors  for  array  processing,  pattern  requirements, ^ommunications^end — 
jhere  is  no  reason  individual  processors  cannot  be  assigned  for  specific  batch 
and  interactive  tasks.  This  can  be  true  whether  the  processors  are 
geographically  or  architecturally  distributed. 

As  far  as  systems  structure  is  concerned,  VM  leads  into  this  rather 

convenientlMb£virtual;*real  can  be  substituted  over  a  period  of  time  for 

machines  as  well  as  for  storage.  The  thing  Wmcn  gets  eliminated  on  the  real 

-To  U-toUaj-N 

processor  is  the  burden  of  a  multiprogramming  operating  system. 

■4  A 
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PERIPHERAL  STORAGE  MANAGEMENT 

It  was  stated  earlier  in  this  section/that  centralized  storage  managment  is 
highly  desirable,  if  not  essentia^  t^a  distributed  processing  environment.  This 
did  not  imply  that  all  physical  storage  had  to  be  centralized,  and  most 
certainly  did  not  mean  that  data  base  management  systems  a^necessarily 
implemented  in  software  under  generaUpurpose  operating  systems. 

A 

INPUT  presented  an  argumen^for  the  desirability  (andeyer)  necessity)  for 
data  base  machine^Jn  Relational  Data  Base  De^lopmentsj(Auqust  1 983j3nd 
will  not  repeat  the  full  analysis  here  except  to  state  that:  "  ^ 


The  IBM/360/370  architecture  is  not  especially  well  suited  for  data 
base  management  purposes. 

There  is  a  need  for  various  data  models  (hierarchical,  network, 
relationaD^and  performance  assistance  will  be  necessary  if  these 
models  are  to  co-habit  (in  the  network  as  well  as  on  a  single  system). 


DB2  with  IMS  or  larr^ge-scale  IBM  mainframes  will  bring  the 
performance  problem  into  fefces. 


Data  base  machines  will  be  necessary. 


This  argument  for  the  architectural  distributions' of  mainframe  processing 
represents  both  the  differentiation  and  mechanization  of  the  data  base 
management  functions.  A  similar  case  can  be  made  for  the  geographic 
distribution  of  large  data  bases  %  other  words,  ^break'tnem  up  into 
manageable  pieces.)  ^  aAymt^t  t«*V  Jjfl 

The  operation  of  the  JOIN  operation  \p  relational  data  base  systems  has 
the  disturbing  property  of  having  the  computational  cost  (number 
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ofcomparisons)  increase  more  rapidly  than  n  (the  number  of  elements 
irrthe/fables).  Jt  will  be  necessary  to  limit  the  size  of  relational  data 


% 


bases. 

The  same  argument  can  be  applied  toany  large  data  basew^for  example 
it  is  substantially  more  cost-effective  to  break  down  directory 
assistance  for  telephone  numbers  or  the  Sears  credit  file  on  a  local 
basis  than  it  is  to  h^e  one  massive  data  base.  The  fact  that  there  are 
very  large  central  data  bases  ignores  the  current  economics 
of^omputer/communication  networks.  The  cost  justification  for 
distributing  data  bases  is  rapidly  becoming  more  compelling. 

Questions  of  privacy  and  security  are  also  more  appropriately  and  easily 
managed.  Central  processing  facilities  with  large  data  bases  0^3805  cannot 
easily  be  disconnect  from  the  network,  and  data  bases  of  varying  sensitivity 
are  "on-line"  whenever  the  system  is  operational.  Distributing -individual  fllftfi^* 
sensitive  data  bases  solves  a  lot  of  problems. 

\ 

The  data  bases  can  be  completely  isolated  from  access  onrhe  general 
network.  I 


The  individuals  (or  departmenjj^  using  the  data  base  can  determine  the 
physical  security,  encryption,  and  access  requirements  based  on  their 
specific  requirements. 


The  big  central  target  for  serious  or  playful  hackers  is  eliminated. 

When  considering  backup  of  data  bases,  large  central  facilities  create  the 
problem  of  how  d^you  back-up  the  bac(<^)s. 

y\  .op 

It  is  more  effective  and  economical  to  have  comparable  nciodes  back  each 
bj  Y 

otherjy'wp  using  a  buddy  system.  (For  example,  two  branches  of  a  bank^each 
mirror  the  transactions  and  account  information  of  the  other.) 
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o        Data  bases  placed  as  close  to  the  end  user  as  possible  are  highly  preferable  in 

all  regards— provided  they  can  be  controlled.  Such  control  becomes  simpl/er 

t>v\  <  ' 

when  emphasis  is  p meed  t*p©n  communications  rather  than^data  procesing. 

The  main  thing  ^roScb.  must  be  changed  is  the  fortress-like  structure  of  tk«. 

corporate  data*Ease  function  ,which  is  currently  more  concept  than  reality. 

3.       DOCUMENT  PRODUCTION,  STORAGE^AND  HANDLING 

o        Surrounding  large-scale  systems  today  are  the  centralized  facilities  for 

producing  paper  documents— miles  and  miles  of  pape'documents  wmcb  must  be 

K  © 
printed,  handled  (distributed),  stored^and/or  destroyed.  Intelligent  workstati^s 

on  each  d/sk  may  not  eliminate  the  need  for  paper,  but  as  processing  ar\d  data 

Y  to*  cU-»-tv..'lau^<J  . 

are  distributed  closer  to  eacb/user^o  will  document  production^  Handling 

will  thus  be  easedjanc^the  availability  of  optical  memories  will  permit 

economical  storage-rrpaper  use  will  be  reduced. 

v  J*  ,  V 

o        It  is  probable  that  some  large  central  facilities  will  remain  as  paper  mills. 

For  example,  Readejtpi^est  may  still  be  mailing  out  its  annual  cc^ntest^to 

million  households.  However,  the  major  trend  of  the  I99()js  will  be.paper 

a.    a  "to  A 

reductionrfind  the  big  c^ntrpl  printing  facilities  will  sw*ty  dwindle  away. 


D.  SUMMARY 


Large  central  mainframes  during  the  ^SO's  will  tend  to  become  enormous 
data  base  machines  in  support  of  both  operational  and  decision  support 
systems.  Applications  based  on  these  data  bases  will  tend  to  become 
distributed  (transaction  processing,  editing  of  input,  report  preparation, 
simple  account  ing^and  statistical  arithmetic)  because  of  the 
price/performance  advantages  of  minicomputers  and  microprocessors. 
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The  centralization  of  control  in  large  host  systems  Vhioh  has  been 
characteristic  of  SNA/and  IBMjoperating  systems  in  generajfis  highly 
appropriate^  at  this  time  because^the  rush  to  link  intelligent  workstations  to 
mainframes  has  high  potential  for  the  deterioration  of  data  and  information 
quality.  In  fact,  even  the  original  batch  orientation  IBM  operating  systems 

A 

may  be  an  advantage  in  such  an  environment. 


However,  the  performance  burden  of  IBM  operating  systems  (and  DBMS 
subsystems)  in  the  data  base  environment  wwen  is  envisioned  may  exceed  the 
increases  anticipated  in  processor  performance^.  This  is  especially  true 
because  decision  support  systems  will  require  complex  math^natical  models  if 
these  large  central  data  bases  are  to  be  of  any  practical  value  in  decision 
support.  The  commercial  environment  will  suddenly  change  from  one  in  which 
simple  arithmetic  has  sufficed  to  one  in  which  the  tools  of  operations  research 


oper 

andartificig^Jjnte^lligence  are  appliea^awl  require  computational  capabilities 
i*  b  exceed^today's  supercomputers. 


There  is  the  potential  for  unanticipated  failure  of  such  systemSjAiata  bases 
will  grow  to  the  point  where  they  cannot  be  maintained  or  fc^used  for 
practical  purposes.or  "simple  roauflost"  for  processing  of  decisionmaking 
model  may  exceed  the^capability  or^he^host  system^or  at  least  what  the 
requestor  would  be  willing  to  pay). 

Even  without  catastrophic  failure,  performance  will  dictate  the 
differentiation  and  mechanization  of  both  hardware  and  operating  system^ 
functions  (the  architectural  and  geographic  distribution  of  processing),  and 
data  bases  will^in  tefwvbe  distributed^ak<5^  In  the  1 99cjs,  this  will  lead  to  the 
massive  replacement  of  large-scale  systems  as  we  know  them  today. 


IBM's  tradional  concern  has  been  that  processor  price-performance  would 
improve  more  rapidly  than  the  usery  ability  to  use ik  effectively.  Systems 
software  has  pretwCc more  than  adequate  at  absorbing  technological  advances 
in  processor  performance,  but  IBM  has  remained  reluctant  to  off-load  large 


y 
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1 


mainframes  to  any  significant  degree.  This  may  lead  to  unfortunate 
consequences  for  users  in  the  I980's  as  the  weaknesses  of  large-scale 
hardware/software  systems  are  exposed. 

Users  are  urged  to  anticipate  the  performance  problems  of  the  projected 
large-scale  systems  environment  of  the  1980*5^  Centralized  control  of  data 
and  information  must  be  exercised  in  the  face  of  increased  use  involvement 
in  the  systems  development  process,  but  this  very  involvement  practically 
assures  the  performance  problems  woScb  have  been  outlined.  Therefore,  the 
orderly  distribution  of  processing  and  data  bases  (in  advance  of  IBM's 
schedule)  is  necessgjy  if  unfortunate  surprises  are  to  be  avoided.  This  has 
been  a  recurren  f^ie^(jNPU^  for  eight  years,  and  ^or  reports  this  year 
will  emphasize  what  can  be  done  in  this  regard. 
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Ill       RESIDUAL  VALUE  FORECASTS 


A.  ANNOUNCEMENTS 


When  IBM  announced  the  X  models  of  the  308X  series  in  February,  INPUT 


issued  an  Executive  Bulletin  w+hcq  reached  the  following  preliminary 
conclusions  concerning  that  apizouncement: 


IBM  could  reduce  prices  on  the  308XX  by  a  substantial  amount  and  still 
achieve  traditioc^il  profit  levels. 

The  relatively  modest  price-performance  improvement  meant  a 
substantial  profit  boost  for  IBM,  and  would  provide  flexibility  in  Sierra 
pricing. 


It  seemed  doubtful  that  the  308XX  would  be  field  upgradable  to  Sierra 
(and  that  if  it  were,  the  cost  of  the  upgrade  would  tSKpset  the  price- 


upgrade 

performance  advantages). 


Announcement  and/or  delivery  schedules  of  Sierra  would  be  delayed  to 
permit  the  308XX  profitability  advantages  to  be  exploited. 

"T+raf/ residual  values  of  the  308X  series  would  be  impacted,  but  not  as 
badly  as  some  analysts  originally  thought.  T+rert  since  upgrades  had 
been  made  attractive,  it  was  probable  that  the  used  market  would 
recover  after  the  initial  confusion. 
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INPUT  also  promised  to  review  th^se  preliminary  conclusions  in  this  report. 

Since  then,  IB/JiJ^announced  a  performance  improvement  package  for  the  308X 

of  up  to  6%  greater  internal  throughput  for  $16,000  (May  1984).  Whtf^this 

has  resulted  in  additional  confusion  about  the  purpose  of  the  308XX 

fh4T 

announcement  (some  analysts  are  now  stating^he  308X  is  a  better  deal  than 
the  308XX  for  those  interested  in  imaginative/  upgrading),  ever" preliminary 
conclusions  still  look  reasonably  good. 

The  308XX  can  be  reduced  in  price  substantially  and  still  meet 
traditic^foojectives.  This  will  be  done  in  connect iory^rith  the  SIERRA 
announcement  and  will  provide  considerable  flexibility  in  terms  of  both 
pricing  and  delivery  schedules.  (At  the  same  time,  those  upgraded 
308X  systems  will  probably  lose  a  lot  of  these  appeal.) 


It  still  seems  doubtful  that  the  308XX  will  be  field  upgradable  without 
substantial  impact  on  the  improved  price-performance  of  the  Sierra. 

A 

Practically  everyone  predicts  Sierra  will  be  announced  in  46KJ4,  but 


INPUT  does  not  feel  IBM  is  under  any  great  pressure  to  announce  an 
entire^new  line  of  large-scale  mainframes.  We^lookjfor  something 
different  to  be  announced: 

Perhaps  a  high-end  system  for  those  who  find^the  performance 

-f»v 

of  the  3084  is  not  adequate  to  meet  their  needs. 

And^something  to  fill  the  open  slot  on  the  308XX— perhaps" 
IBM's  version  of  a  data  base  processor. 


Under  any  circumstances,  the  308XX  is  going  to  be  around  in 
some  form  even  after  the  SIERRA  announcomc     or  TROUT  or 
whatever  it  is  currently  being  ca\\ed).ara\o\)^ce^\&t\^» 
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Resijual  values  have  been  impacted,  but  they  still  fall  within  the  range 
of  the  charts  published  in  INPUT's^Residual  Value  Forecasts  for  Larqe- 
Scale  Systems^jpecember  1 983).  (Revised  tables  of  residual  values  for 
the  308X  series  are  included  later  in  this  sectionJ 

In  April,  National  Advanced  Systems  (NAS)  its  AS/80X3  series  of  mainframes 
■wrrre&  will  replace  and  extend  the  former  AS/80xtJ  series.  The  old  series  is 

upgradable^ and  NAS  hailed  this  announcement  as  upholding  "NASrs 
tradition  of  protecting  its  customers'  investments."  Indeed,  there  is  truth  in 
this  statement^&naYresidual  value  forecasts  for  NAS  h<a^n  btiu  huU^uU-al^y^ 
processors  have  been  adjusted  acco/dingly.  (The  AS/80X3  series  covers  a 
range  extending  from  the  IBM  4381-2  through  the  IBM  308 1 KX.) 

In  June,  TRILOGY  (Amdahl  &  Son)  announced  discontinuance  of  its  attempt  to 

enter  the  very  large-scale,  software-compatible  mainframe  market  with  a 

system  based  on  wafer-scale  technology.  The  announcement  followed 

numerous  delays  in  shipment  date,  and  approximately  $250  million  in 

became  *cu)  -J^-f  o»«c«.^ 

financing.  It  is  indeed  unfortunate^there  will  not  be  any  significant 

performance  adjustments  on  large-scale  IBM  systems  comparable  to  those 

resulting  from  Gene  Amdahl's  earlier  effors. 

f 

ited/ n 

represented  a  substantial  change  in  magnetic  tape  technology,  it  fell  short  of 
INPUT'S  expectations. 


-fo'*^;«L«i'"  Y 
price--/ 


In  late  March,  IBM  announced  its  long-awaited/  new  tape  subsystem.  While  it 

A 


V 

Essential  features  of  the  IBM  3480  Tape  Subsystem  are  as  follows: 
h 

Three-megalyte-per-second  data  rate. 

A  \      /\  A 

Lemljr  recording  density  of  approximately  38,000  bits  per  inch, 
on  half-inch  chromium  dioxide  tape  housed  in  a  protective 
plastic  cartridge. 
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18-track  thin-film  read/write  heads. 

A  ^ 

Reliability  through  advanced  component  technology,  new  error 
correction  code,  and  separate  microprocessors  in  each  drive  and 
control  unit. 

The  subsystem  attached  to  the  block  multiplexor  of  the  IBM 
303X,  308X,  434 Land  4381  processor  under  MVS/370  and 
MVS/XA. 


The  units  consume  only  half  Jfie  spaje  and  60%  less  power  and 
cooling  capacity  than  the  3420. 

General  availability  will  be  in  the  first  quarter  of  1985. 

It  was  generally  felt  that  because  of  cost  (a  "typical"  3480  subsystem 
consisting  of  one  controller  and  eight  drives  costs 

conversion  problems,  the  3480  will  not  replace  the  venerable  3420  tape 
technology. 

The  announcement  leaves  a  substantial  problem  of  3380^fi I  dumping  and 
backup  for  large  mainframe  sitesT^problem  whi«h  will  ©nty  be 
compounded  as  more  on-line  storage  is  added.  There  are  already 
rumors  of  new  technology  (perhaps  optical  disk?)  to  address  the 
problem. 


B.       USEPrMARKET  ACTIVITY 

a.  irv 

o         Used-market  activity  and  prices  are  a  m^jor  determin^j  factor  in  the  residual 
value  of  installed  equipment.  Exhibit  III-I  and  111-2  present  used  market 
average  retail  prices  for  selected  IBM  peripheral  and  mainf ranrjs  (as  a  percent 
of  IBM  list  price). 
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The  used  market  for  peripherals  has  not  changed  substantially  from  that 
described  in^Large-Scale  Systems  Directions:  Disk,  Tape^ind  Printer 
Sj^ems^arch  198^  "  '        *  > 

The  3480-B22  magnetic  tape  subsystem  is  currently  selling  at  an  early 
shipment  premium  awaiting  volume  shipment  in  the  first  quarter  of 
1985.  The  market  for  3420  models  has  generally  remained  stable  since 
the  announcement  of  the  34£J0. 

/ 

The  3350  is  going  through  another  temporary  resurgence  as  the  over^- 
supply  created  by  3380  replacement  of  installed  3350's  has  slackened. 

/ 

The  announcement  of  the  308XX  series  of  processors  has  had  a  generally 
depressing  effect  on  used^market  prices  for  308X  equipment,  but  the  general 
used-market  trend  downwards  had  already  been  established  last  year.  The 
effect  of  the  performance  improvement  package  (coupled  with  the  cheap 
upgradabilityjfwtesn  was  mentioned  earlierjshould  have  the  effect  of  firming 


the  large-mainframe  market. 
A  a 


up  the  used  market  for  308X  processor,  but  this  4s  a  year  of  general  confusion 


C.       PROJECTED  RESIDUAL  VALUES 


-Exhibit  1 1 1—3  ui id  111-4  present  projected  used  icroil  prices  for  selecfecl  IOM 
ITeTiplieTols^stoi^d-m- dollars  and-es-erpercent  of  current  IDM  list  price. 

Exhibit  Ill-S^and  lll-6rpresent  the  projected  used^narket  retail  value  in  dollars, 
and  the  projected  residual  value  of  IBM  and  software-compatible  mainframes 
as  a  percent  of  vendor  list  price.  Exhibit  III-?' through  lll-l^graph  the  range 
of  anticipated  values  (as  a  percent  of  list  price)  for  1985  through  1989  for 
selected  processor/f  \ 
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I 

IBM  43fg&  4361,  4381,  3083EX,  3083 JX,  308 1 GX,  308 1 KX,  and 
3084QX. 

Amdai?l^  5860  and  5870. 


NAS  6000,  8000,  and  9000. 
U 

The  vales  shown  are  wholesale  prices— the  amount  a  used-computer  dealer  will 
pay  for  equipment  for  subsequent  resale  to  an  end  usera4-oHn^l3et4>dc£p  The 
factors  affecting  computer  equipment  residual  values  were  presented  in 
•^Residual^Vajue  Forecasts  for  Larqe-Scale  System s*^December  1983.  Those 

factors  have  redKayed  detailed  analysis  in  the  past  as  part  of  INPUT'S  residual 

.  -screes, 
value  service. 
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EXHI  BIT  II-/  ^ 
LARGE  HOST  DATA  BASE  MACHINES 


Large  Host 
Processors 


DB2 

Tables 

Distributed 
Processors 


Intelligent 
Workstations 


A 


i.ii.  mil 


1  Schedule  Batch  Requests 

(a)  Extracts  from  File  to  Build 
'  DB2  Tables. 

(b)  Updating  of  Data  Bases. 

@  Backup  of  Host  &  Distributed 
Data  Bases. 

(d)  Extract  and  Transmission  of 
Data  Bases. 

(e)  Heavy  Computation. 

2  Interactive  Processing 

(a)  IMS  Data  Bases. 

(b)  DB2  Tables. 

3  Protection  &  Security 

(?)  File  &  Data  Base  Access. 

(b)  Data  Base  Update. 

@  File  Syncronization  &  Integrity. 

(d)  Certified  Files  &  Data  Bases. 

(e)  Monitor  Information  Flow. 
(?)  Control  Encryption. 
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EXHIBIT  111-1 


USED  MARKET  AVERAGE  RETAIL  PRICES  FOR 
SELECTED  IBM  PERIPHERALS 
(As  a  Percent  of  IBM  List) 


Model 

1982 

1983 

1984 

 1 

Market 
lrend 

December 

March 

3une 

September 

December 

March 

3330-001 

3% 

3% 

3% 

2% 

1% 

1% 

Down 

3330-011 

4 

3 

3 

2 

1 

1 

Down 

3350-A02 

52 

52 

55 

38 

25 

32 

Up 

3350-B02 

53 

53 

55 

38 

25 

32 

Up 

3380-AA4 

103 

101 

101 

93 

93 

90 

Stable 

3380-B04 

103 

101 

101 

93 

93 

90 

Stable 

3420-003 

8 

8 

8 

7 

5 

5 

Down 

3420-005 

10 

10 

10 

12 

12 

12 

Stable 

3420-007 

13 

17 

17 

21 

28 

28 

Stable 

3420-004 

55 

55 

57 

68 

63 

60 

Stable 

3420-006 

54 

50 

58 

75 

70 

70 

Stable 

3420-008 

69 

67 

71 

93 

93 

88 

Stable 

3480-B22 

112 

Down 

1403-N01 

7 

5 

4 

3 

3 

3 

Down 

3211-001 

50 

55 

55 

57 

52 

48 

Down 

3800-001 

63 

63 

60 

58 

58 

56 

Down 

The  values  shown  are  used-market  retail  prices.  At  any  given  time,  three 
price  levels  exist: 

Retail  Price  -  The  amount  an  end  user  would  pay  for  the  equipment. 

Dealer  Price  -  The  amount  a  dealer  would  pay  another  dealer  to  acquire 
equipment  to  complete  a  contracted  sales  obligation. 

Wholesale  Price  -  The  amount  a  dealer  would  pay  to  acquire  equipment  for 
resale. 

The  dollar  spread  between  levels  is  a  function  of  the  total  value  of  the 
transaction.  For  large  processors  the  wholesale  price  will  typically  be 
80%  to  95%  and  for  peripheral  equipment  70%  to  90%  of  the  retail  price. 
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EXHIBIT  1 1 1  —2 

USED  MARKET  AVERAGE  RETAIL  PRICES  FOR 
SELECTED  IBM  LARGeTmAI NFRAMES 
(As  a  Percent  of  IBM  List) 


Model 

1982 

1983 

1984 

Market 
Trend 

December 

March 

June 

September 

December 

March 

4331-1 

58 

55 

51 

42 

41 

O  LaU  It: 

4331-2 

63 

60 

60 

60 

64 

62 

Stable 

4341-1 

78 

71 

71 

67 

57 

41 

Down 

4341-2 

79 

75 

75 

67 

58 

55 

Down 

3031-6 

6 

5 

5 

4 

3 

2 

Down 

3032-8 

7 

5 

4 

4 

3 

Down 

3033-N 

28 

26 

24 

15 

13 

6 

Down 

3033-U 

30 

28 

25 

20 

14 

11 

Down 

3083-E 

88 

81 

Down 

3083-B 

90 

82 

Down 

3083-J 

90 

82 

Down 

3081-D 

90 

85 

88 

85 

80 

80 

Down 

3081-K 

94 

92 

92 

90 

85 

85 

Down 

The  values  shown  are  used-market  retail  prices.  At  any  given  time,  three 
price  levels  exist:  ^ 

Retail  Price  -  The  amount  an  end  user  would  pay  for  the  equipment. 

Dealer  Price  -  The  amount  a  dealer  would  pay  another  dealer  to  acquire 
equipment  to  complete  a  contracted  sales  obligation. 

Wholesale  Price  -  The  amount  a  dealer  would  pay  to  acquire  equipment  for 
resale. 

The  dollar  spread  between  levels  is  a  function  of  the  total  value  of  the 
transaction.  For  large  processors  the  wholesale  price  will  typically  be 
80%  to  95%  and  for  peripheral  equipment  70%  to  90%  of  the  retail  price. 
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EXHIBIT  III-*' 


PROJECTED  USED-MARKET  RETAIL  VALUE  AT  JANUARY  1 

($  Thousands^  ^ 


VENDOR 

PROCESSOR 
MODEL 

CURRENT 
LIST 

6/1/84 

1  7uJ 

1Q8£ 
I  jod 

1  no  o 

1 988 

1989 

IBM 

4331-JOl 
4331-K02 
4341 -KOI 
4341-L02 
4361-0K4 
43B1-0K5 

60920 
90000 
1 84500 
312000 
150000 
200000 

21322 
57600 
77490 
149760 
130500 
1 800OO 

15839 
43200 
5 1 660 
109200 
1 1 4000 
1 64000 

9747 
29700 
25830 
62400 
90000 
140000 

4264 
10800 

9225 
24960 
60000 
96000 

2437 
6300 
5535 
15600 
1 9500 
40000 

3033-NOB 
3033-U12 

1474000 
1964000 

88440 
157120 

44220 
157120 

14740 
157120 

14740 
157120 

0 

157120 

30B3-E08 
30B3-B08 
30B3-J08 
3083-EXB 
30B3-BXB 
3083-JX8 

1 1 90000 
1805000 
2330000 
1 1 90000 
1 805000 
2330000 

797300 
1227400 
1631000 
101 1500 
1534250 
1980500 

559300 
902500 
1 1 88300 
737800 
1173250 
1561100 

297500 
505400 
699000 
571200 
902500 
1 1 88300 

l 07 l 00 
198550 
326200 
190400 
342950 
489300 

35700 
90250 
163100 
95200 
1 80500 
256300 

3081 -G24 

3081-K24 

30B4-Q32 

30B1-GX24 

3081-KX24 

30B4-BX32 

3325000 
3855000 
* 

3325000 
3855000 
* 

2161250 
2698500 

2B59500 
3469500 

1596000 
2120250 

1762250 
2274450 

897750 
1349250 

1064000 
1464900 

299250 
539700 

399000 
616800 

99750 
231300 

166250 
308400 

AMDAHL 

470-V7 
470-V8 

0 
0 

0 
0 

0 
0 

O 
O 

0 
0 

5B40-16 
5850-24 
5860-24 

5867-  24 

5868-  32 
5870-32 
5880-48 

2000000 
2660000 
29 1 0000 
3560000 
4070000 

—  \J  £^  'J  'J  *J  'J 

5340000 

1 800000 
2394000 
1949700 
3382000 
3B66500 

4272000 

1040000 
1436400 
1455000 
2171600 
2564100 
271 2000 
2776800 

700000 
984200 
989400 
1 352800 
1 668700 
1 762800 
1975800 

340000 
532000 
436500 
605200 
895400 
858800 
96 1 200 

1 80000 
266000 
232800 
391600 
569800 
542400 
534000 

NAS 

AS/6620 
AS/6630 
AS/6650 

255000 
341500 
417500 

127500 
191240 
250500 

71400 
1 12695 
146125 

35700 
61470 
91850 

12750 
27320 
50100 

7650 
17075 
37575 

AS/ 8023 
AS/8043 
AS/ 8053 
AS/8063 
AS/80B3 

639000 
1255000 
1758000 
2251000 
3506000 

607050 
1029100 
1459140 
2251000 
n/a 

332280 
690250 
1 002060 
1 350600 
2454200 

210B70 
439250 
632880 
877890 
1507580 

76680 
188250 
263700 
382670 
701200 

38340  ' 
1 00400 
158220 
247610 
490840 

AS/9040 
AS/9050 
AS/9060 
AS/9070 
AS/ 9080 

1 758000 
2256000 
2729000 
3706000 
4722000 

632880 
902400 
1 173470 
1 853000 
2833200 

35 1 600 
564000 
01 8700 
1 556520 
2361000 

158220 
270720 
491220 
QB9440 
1416600 

87900 
157920 
272900 
555900 
849960 

35  1 60 
90240 
163740 
296480 
472200 
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EXHIBIT  III-J6- 

PROJECTED  RESIDUAL  VALUES  FOR 
IBM  AND  SOFTWARE-COMPATIBLE  MAINFRAMES 


PROJECTED  RESIDUAL  VALUE  AS 

PERCENT  OF  VENDOR  LIST  PRICE 

VENDOR 

PROCESSOR 

AS  OF  JANUARY  1 

MODEL 

1985 

1986 

1987 

1988 

1989 

IBM 

4331-1 

35 

26 

16 

7 

if 

4331-2 

64 

48 

33 

12 

7 

4341-1 

42 

28 

14 

5 

3 

4341-2 

48 

35 

7f) 

5 

5 

4361-1 

86 

74 

56 

35 

in 

4361-2 

87 

76 

60 

40 

13 

4381-1 

88 

80 

65 

W7 
tz 

14 

4381-2 

90 

83 

70 

to 

20 

3033-N 

6 

3 

■ 

i 

1 

3033-U 

8 

5 

3 

9 

■ 
i 

3083-E 

67 

47 

25 

9 

3 

3083-B 

68 

50 

28 

11 

5 

3083-3 

70 

s  i 

7 

3083-EX 

85 

62 

48 

16 

a 

8 

3083-BX 

85 

65 

50 

19 

10 

30X3-1X 

85 

b/ 

51 

21 

11 

3081-G 

65 

4  o 

27 

9 

3 

3081-K 

70 

55 

35 

14 

6 

78 

61 

40 

18 

9 

insii  r.Y 

j\Jo  1  — Vj  A 

86 

53 

32 

12 

5 

-anR  l  KY 

JUO  1    I\  A 

90 

59 

38 

16 

8 

90 

65 

44 

21 

1 1 

AMDAHL 

470-V/7 

7 

2 

1 

1 

4 /U- V/5 

i  n 

7 

5 

2 

1 

90 

52 

35 

17 

9 

90 

54 

37 

20 

10 

5860 

67 

50 

34 

15 

8 

5867 

.  95 

61 

38 

17 

11 

5868 

95 

63 

41 

22 

14 

5870 

90 

60 

39 

19 

12 

5880 

80 

52 

37 

18 

10 

NAS 

AS/6620 

50 

28 

14 

5 

3 

AS/6630 

56 

33 

18 

8 

5 

AS/6650 

60 

35 

22 

12 

9 

AS/8023 

95 

52 

33 

12 

6 

AS/8043 

82 

55 

35 

15 

8 

AS/8053 

83 

57 

36 

15 

9 

AS/8063 

100 

60 

39 

17 

11 

AS/8083 

70 

43 

20 

14 

AS/9040 

36 

20 

9 

5 

2 

AS/9050 

40 

25 

12 

7 

4 

AS/9060 

43 

30 

18 

10 

6 

AS/9070 

50 

42 

24 

15 

8 

AS/9080 

60 

50 

30 

18 

10 
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EXHIBIT  III-?- 


RESIDUAL  VALUE  FORECAST  FOR 
IBM  4341-2  PROCESSOR 


PROJECTED 
VALUES  RANGE 

JAN  . 

1  985 

JAN. 

1  986 

JAN. 
1  987 

JAN. 

1  988 

JAN. 

1  989 

High 

54 

38 

22 

10 

8 

Expected 

48 

35 

20 

8 

5 

Low 

35 

22 

10 

5 

3 
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EXHIBIT  111-8- 

RESIDUAL  VALUE  FORECAST 

FOR  IBM  4361  PROCESSOR 

J 


Jan.  1984      Jan.  1  985     Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN  . 
1985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 
1  989 

High 

92 

85 

68 

50 

18 

Expected 

87 

76 

60 

40 

13 

Low 

84 

68 

48 

28 

6 
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EXHIBIT  ' 

RESIDUAL  VALUE  FORECAST  FOR 
IBM  4381  PROCESSOR 


Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN  . 

1  985 

JAN. 
1  986 

JAN. 

1  987 

JAN. 
1  988 

JAN. 
1  989 

High 

92 

88 

78 

56 

28 

Expected 

90 

83 

70 

48 

20 

Low 

86 

75 

57 

36 

8 
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EXHIBIT  lll-ie 

RESIDUAL  VALUE  FORECAST  FOR 
IBM  3083EX  PROCESSOR 


Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN. 

1985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 
1  989 

High 

90 

67 

55 

25 

12 

Expected 

85 

62 

48 

16 

8 

Low 

78 

55 

40 

10 

4 
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EXHIBIT  III-JH- 
RESIDUAL  VALUE  FORECAST  FOR 


Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN  . 
1  985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 
1  989 

High 

90 

75 

60 

30 

18 

Expected 

85 

67 

51 

21 

11 

Low 

78 

60 

42 

15 

5 
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exhibit  \w-ir  x£> 

RESIDUAL  VALUE  FORECAST  FOR 
IBM  3081GX  PROCESSOR 


Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN. 
1985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 
1  989 

High 

90 

60 

40 

18 

10 

Expected 

86 

53 

32 

12 

5 

Low 

82 

48 

28 

9 

3 
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EXHIBIT  III 

RESIDUAL  VALUE  FORECAST  FOR 
IBM  3081KX  PROCESSOR 


Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987  Jan. 


PROJECTED 
VALUES  RANGE 

JAN. 
1985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 
1  989 

High 

95 

65 

45 

20 

12 

Expected 

90 

59 

38 

16 

8 

Low 

82 

50 

32 

10 

6 
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Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN  . 

1  985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 

1  988 

JAN. 

1  989 

High 

95 

75 

50 

30 

15 

Expected 

90 

65 

nn 

21 

11 

Low 

82 

52 

35 

15 

7 
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EXHIBIT  lll-O^ 

RESIDUAL  VALUE  FORECAST  FOR 
AMDAHL  5860  PROCESSOR 


100% 
90 


80 


70 


Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN. 
1  985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 

1  989 

High 

58 

45 

22 

15 

Expected 

67 

50 

34 

15 

8 

Low 

36 

18 

9 

3 
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EXHIBIT  \\\-#T^ 

RESIDUAL  VALUE  FORECAST  FOR 
AMDAHL  5870  PROCESSOR 


0  I  1  1  1  I  |  | 

Jan.  1  984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN  . 

1  985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1988 

JAN. 
1  989 

High 

95 

72 

45 

25 

18 

Expected 

90 

60 

39 

19 

12 

Low 

83 

48 

27 

12 

6 
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EXHIBIT  III 


RESIDUAL  VALUE  FORECAST  FOR 
NAS  6000  SERIES  PROCESSOR 


100lr 


90 


80 


70 


60 


50 


40 


30 


20 


10 


Jan.  1984      Jan.  1  985     Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANCE 

JAN  . 

1  985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 

1  988 

JAN. 
1  989 

High 

42 

30 

20 

12 

Expected 

60 

35 

22 

12 

9 

Low 

30 

15 

8 

5 
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EXHIBIT  Wl-XB 

RESIDUAL  VALUE  FORECAST  FOR 
NAS  8000  SERIES  PROCESSOR 


Jan.  1984      Jan.  1  985     Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN. 
1  985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 

1  989 

High 

72 

45 

28 

15 

Expected 

95 

60 

38 

21 

10 

Low 

54 

30 

11 

6 
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EXHIBIT  III- 

RESIDUAL  VALUE  FORECAST  FOR 
NAS  9000  SERIES  PROCESSOR 

100%i  1  1  1  .  

90  

80  

70  I  1  I  I  

60 
50 
40 
30 
20 
10 


0 

Jan.  1984      Jan.  1  985      Jan.  1  986       Jan.  1  987      Jan.  1  988      Jan.  1989 


PROJECTED 
VALUES  RANGE 

JAN  . 
1  985 

JAN. 
1  986 

JAN. 
1  987 

JAN. 
1  988 

JAN. 
1  989 

High 

57 

36 

25 

15 

Expected 

60 

50 

30 

18 

10 

Low 

42 

25 

12 

7 
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